Apple Blossom
   |
Posted - 2007.06.28 04:27:00 -
[1]
 Originally by: Chelone
Originally by: ZenThunder
The technology currently DOES NOT EXIST to provide 1000 ship battles that are playable within the current budget of CCP. PERIOD.
You can have ship battles in the thousands. The code to implement it would just need to seriously streamline what information is being sent, when, and how. The problem is, we seem to be going in the OPPOSITE DIRECTION. The recent changes have made things WORSE, not better. So the new, inefficient / borked code now makes 100 vs 300 a useless exercise. We used to do better than that... which makes me think it is due to them piling more new features (heat?) on an already overloaded combat system, pardon the pun.
Server tasks / cycle:
S1.) Read commands from X Clients, implement changes (on/off, destination/speed, etc.)
S2.) Calculate interactions in position/damage/effects from N*X sources, where N is the number of relevant modules/drones/other sources of interest per player. Could stack geometrically up to (N*X)^2, but optimization based on "spheres of influence" of any given module should greatly reduce this problem.
S3.) Send the results of up to (N*X)^2 effects back to X Clients -- result: up to N^2 * X^3 info packets sent.
Client tasks / cycle:
C1.) Read in up to (N*X)^2 info packets from server and update status of X players and their modules accordingly.
C2.) Perform as much client-side calculation as possible to reduce server load, without allowing cheating/hacking.
C3.) Graphically Render X players and their module effects.
C4.) Read and send commands to server.
So in this analysis, we actually have a load problem scaling with the CUBE of the number of users, rather than the square. (X users interacting with X users, and results being sent to X users.) Still. Does user 23 really need to know whether user 746's afterburner is activated, or whether he has targeted user 413? Streamlining this is probably the key.
I think, with the patch, N has increased with the new features, so now the number of X the server can handle has been reduced, for the same limiting factor of N^2 * X^3. If it is a load problem, and not a bug, it would really seem to lie in server steps S2 (calculation) or S3 (transmission.) In any case, if the only solution is a separate "Large Fleet Combat Mode", I'd support it.
This is serious back of the envelope stuff, but I like this analysis, so lets plug in some numbers:
Number of players: 100 (50 vs 50)
Avr Number of 'relevant' player information required by other players: 10 (speed, direction, shields, armour, structure, some modules...)
10^2 * 100^3 = 100,000,000 'packets' sent/received/processed by the server to update game state (call each update a 'frame').
Lets assume 10 bytes per 'packet' = 1,000,000,000 bytes per update = 1GB.
So a node with a 50 vs 50 battle has to send and process in the order of 1GB of information per 'frame'.
250 vs 250 this becomes 10^2 * 250^3 * 10 = 12,500,000,000 = 12.5GB of information per frame.
500 vs 500 = 100GB per frame
I'm sure these numbers are out by several orders of magnitude, but maybe they give some indication of the scale of the programming challenge.
|